home *** CD-ROM | disk | FTP | other *** search
/ BMUG Revelations / BMUG Revelations.toast / Utilities / System 7 / ICONOpen! / Read Me < prev   
Text File  |  1992-11-19  |  6KB  |  68 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6. ©1992 by Carl Smigielski
  7. Version 1.0
  8.  
  9. THIS PROGRAM IS SHAREWARE.  Don't be a sleaze!  If you use this system extension regularly, the author requests payment of $10.00. 
  10.  
  11. Mail large sums of cash to:
  12. CARL SMIGIELSKI
  13. P.O. Box 21
  14. West Kingston, Rhode Island, USA
  15. 02892-0021
  16.  
  17. The author can be reached on:
  18. AMERICA ON LINE -- CarlS22
  19. COMPUSERVE -- 70042,437
  20.  
  21.  
  22. About ICONOpen!
  23. -------------------------------
  24.  
  25. ICONOpen! adds a simple, but powerful, item to the standard "Open File..." dialog boxes.  As you navigate through your files, folders, and disks, ICONOpen! displays the icon of the current selection.  If a selected file is already open, ICONOpen! displays its icon in the "opened" state.  If the icon has been assigned a label color in the Finder, the icon is displayed as such.
  26.         ICONOpen! fully supports the display of custom icons, making it invaluable when browsing files created by applications like Adobe Photoshop®, which create miniature representations of their documents as icons.
  27.         In addition, ICONOpen! displays the type of file selected, and the name of the application which created it.
  28.  
  29. Requirements
  30. -------------------------------
  31.  
  32. ICONOpen! requires System 7.0 or higher.  It will run on any Macintosh.  ICONOpen! adds about 45 pixels to the bottom of the "Open File..." dialog boxes.  If you have a classic Mac, and an application's "Open File..." dialog box already fills your screen, you may not see the ICONOpen! items.
  33.  
  34. Installation
  35. -------------------------------
  36.  
  37. ICONOpen! is a system extension, and should be placed in the "Extensions" folder inside your "System Folder".  Dragging ICONOpen! to your CLOSED "System Folder" will automatically install it in the correct place.  ICONOpen! will not start working until after you restart your Mac.
  38.  
  39. Features
  40. --------------------------------
  41.  
  42. ICONOpen! goes into action anytime your application displays a dialog box for selecting a file.  Most commonly, this is when you select "Open..." from the "File" menu.  However, in many programs, ICONOpen! works at other times.  For example, in PageMaker®, selecting "Place..." will display a file selection dialog box.  ICONOpen! works here too!
  43.  
  44.         ICONOpen! supports double-clicking on its icons.  If the icon represents a folder, or a volume, double-clicking on it opens that folder and displays its contents.  If the icon represents a file, double-clicking on it closes the dialog box, and opens that file.  
  45.  
  46.         If the file, folder, or volume you've selected has a custom icon, ICONOpen! will display it.  Some programs, like Adobe Photoshop®, create custom icons which are miniature representations of their file's contents.  Before ICONOpen!, the only way to view these custom icons was in the Finder.  Now you can see these miniature pictures where they're most needed -- in the "Open File..." dialog box!
  47.  
  48.         ICONOpen! displays icons using the current label colors assigned to them in the Finder. 
  49.  
  50.         ICONOpen! also displays the file type of the currently selected file.  A "file type" is a four letter sequence, which indicates (surprise!) the type of data in a file.  Standard file types are 'TEXT' (for text files), and 'PICT' (for pictures).  Many applications define their own file types.
  51.  
  52.         ICONOpen! tries to display the name of the application that created the file you've selected.  However, if the creator application is not on any of your mounted disks, ICONOpen! cannot determine the name, and will display the default words "document" instead.  If you have several mounted volumes, and the creator of the selected file is not on the same volume as the file, there may a tiny delay as ICONOpen! searches all your volumes.
  53.  
  54.  
  55. Technical Stuff
  56. --------------------------------
  57.  
  58. You don't have to read this.  But chances are some of you are avid "PowerUsers", or (gasp!) maybe even developers, and the stuff that preceeded seemed very lame.
  59.  
  60.         ICONOpen! patches _Pack3 and _NewDialog.  The code first checks whether the _Pack3 selector indicates any of the GetFile calls.  With the advent of System 7, there are now four possible calls, StandardGetFile, CustomGetFile, SFGetFile, and SFPGetFile.  All these calls support a dialog hook, except for StandardGetFile.  StandardGetFile is coerced into a call to CustomGetFile.  
  61.         Next, ICONOpen! retrieves the address of the calling code's dialog hook (if any), and replaces it with it's own dialog hook.  In addition, the SFReply (or StandardFileReply, if applicable), passed to _Pack3 is copied to a global variable, for reference in the ICONOpen! dialog hooks.  After all this back alley stuff, the original, unsuspecting, _Pack3 is called.  The _Pack3 patch is the only part of ICONOpen! written in assembly.  The rest of the code was written in THINK C 5.0.
  62.         The patch to _NewDialog is needed to ensure a color dialog is created.  Back at _Pack3, a global Boolean variable was set to indicate that the next call to _NewDialog will be from _Pack3.  _NewDialog immediately resets this variable, and calls _NewCDialog with the same parameters it was passed.  Had to do this folks!  Otherwise many, many, many applications would not display icons in color.  If _Pack3 is not the caller to _NewDialog, the patch does nothing.  Almost as sleazy as a tail patch, but much safer (I hope!).
  63.     Two separate dialog hooks were coded, one for the old style calls that use a SFReply, and one for the new calls which use a StandardFileReply.  Believe me, the new calls are MUCH easier!  By the way, is it common knowledge that when the user selects a folder under the old calls, the SFReply.fType field is set to the hard DirID of the folder?  I almost wet my pants when I accidentally discovered that one!  Only way to extract the folder's name, if you catch my drift.
  64.         The inner workings of the ICONOpen! dialog hooks are very dull, so I won't bore you with them (grin).  They've been beta tested under many applications and on several machines.  But that doesn't mean they always work.  I've been programming on the Mac for only a few months, and I taught myself assembly by watching things in MacsBug.  If you have any trouble with ICONOpen!, please don't hesitate to drop a line.  Also, any ideas for future features would be appreciated! 
  65.         Enjoy!
  66.         
  67.  
  68.